Computing devices have made significant contributions toward the advancement of modern society and are utilized in a number of applications to achieve advantageous results. Numerous devices, such as personal computers, laptop computers, servers, minicomputers, mainframe computers, workstations, and distributed computer systems, have facilitated increased productivity and reduced costs in analyzing and communicating data in most areas of business, science, education and entertainment. As computing devices continue to progress one technique for achieving increased performance is virtualization.
The advantages of virtual machine technology have become widely recognized. Among these advantages is the ability to run multiple virtual machines on a single host platform. Running multiple virtual machines makes better use of the capacity of the hardware, while still ensuring that each user enjoys the features of a “complete” computer. Depending on how it is implemented, virtualization can also provide increased security, since the virtualization can isolate potentially unstable or unsafe software so that it cannot adversely affect the hardware state or system files required for running the physical (as opposed to virtual) machine.
A virtualization of a physical computing device typically creates a uniform hardware image, implemented in software, on which operating systems and applications run. The virtualization architecture may provide management and provisioning of virtual machines, continuous workload consolidation across physical computing devices and mobility of virtual machines between physical computing devices. Each virtual machine is a software representation of a physical machine that can run or host a guest operating system and one or more applications.
Virtualization provides a layer of abstraction between the physical computing, storage and networking hardware and the operating system(s) and applications running on the computing device. Virtualization may be implemented by a hosted architecture or a non-hosted architecture. Virtualization terminology has evolved over time and has not yet become fully standardized. Nonetheless, for purposes of this patent, a virtualization system implementing a non-hosted architecture is referred to as a “hypervisor” implementation.
A hosted approach provides partitioning and other virtualization services with the assistance of a standard operating system and typically supports a broad range of hardware configurations. The virtualization software relies on the host operating system to provide some of the services to talk directly to the underlying hardware.
In a hypervisor implementation, the hypervisor is the lowest layer of software installed on a physical computing device (e.g., x86-based computing system). In a typical hypervisor architecture, a thin layer of software that implements partitioning and other lower-level virtualization capabilities runs directly on hardware, but underneath the software that implements higher-level virtualization services.
Referring to FIG. 1, one possible arrangement of a computer system 100 that implements virtualization, according to the conventional art, is shown. One or more virtual machines (VMs) or “guests” 102, 104 are installed on a “host platform,” or simply “host,” which will include system hardware, that is, a hardware platform 106, and one or more layers or co-resident components comprising system-level software, such as an operating system or similar kernel, a virtual machine monitor or hypervisor (see below), or some combination of these. The system hardware typically includes one or more processors 108, memory 110, some form of mass storage 112, and various other devices 114.
Each VM 102 will typically have both virtual machine hardware 118 and guest system software 116. The virtual machine hardware 118 typically includes at least one virtual CPU 120-124, virtual memory 126, at least one virtual disk 128, and one or more virtual devices 130. Note that a disk—virtual or physical—is also a “device,” but is usually considered separately because of the important role of the disk. All of the virtual hardware components of the VM may be implemented in software using known techniques to emulate the corresponding physical components. The guest system software 116 includes a guest operating system (OS) 132 and drivers 134 as needed for the various virtual devices 130.
Note that a single VM 102 may be configured with more than one virtualized processor 120-124. To permit computer systems to scale to larger numbers of concurrent threads, systems with multiple CPUs 108 have been developed. These symmetric multi-processor (SMP) systems are available as extensions of the PC platform and from other vendors. Essentially, an SMP system is a hardware platform that connects multiple processors to a shared main memory and shared input/output (I/O) devices. Virtual machines may also be configured as SMP VMs. FIG. 1, for example, illustrates multiple virtual processors (VCPU0, VCPU1, VCPUm) within the VM 102.
Yet another configuration is found in a so-called “multi-core” architecture, in which more than one physical CPU 108 is fabricated on a single chip, with its own set of functional units (such as a floating-point unit and an arithmetic/logic unit ALU), and can execute threads independently; multi-core processors typically share only very limited resources, such as some cache. Still another technique that provides for simultaneous execution of multiple threads is referred to as “simultaneous multi-threading,” in which more than one logical CPU (hardware thread) operates simultaneously on a single chip, but in which the logical CPUs flexibly share some resource such as caches, buffers, functional units, etc. This invention may be used regardless of the type—physical and/or logical—or number of processors included in a physical machine and/or VM.
If the VM 102 is properly designed, applications 134 running on the VM 102 will function as they would if run on a “real” computer, even though the applications are running at least partially indirectly, that is via the guest OS 132 and virtual processor(s) 120-124. Executable files will be accessed by the guest OS 132 from the virtual disk 128 or virtual memory 126, which will be portions of the actual physical disk 112 or memory 110 allocated to that VM 102. Once an application is installed within the VM 102, the guest OS 132 retrieves files from the virtual disk 128 just as if the files had been pre-stored as the result of a conventional installation of the application. The design and operation of virtual machines 102 are well known in the field of computer science.
Some interface is generally required between the guest software within a VM 102 and the various hardware components and devices in the underlying hardware platform. This interface—which may be referred to generally as “virtualization software”—may include one or more software components and/or layers, possibly including one or more of the software components known in the field of virtual machine technology as “virtual machine monitors” (VMMs) 136, 138, “hypervisors,” or virtualization “kernels.” Because virtualization terminology has evolved over time and has not yet become fully standardized, these terms do not always provide clear distinctions between the software layers and components to which they refer. For example, “hypervisor” is often used to describe both a VMM and a kernel together, either as separate but cooperating components or with one or more VMMs incorporated wholly or partially into the kernel itself; however, “hypervisor” is sometimes used instead to mean some variant of a VMM alone, which interfaces with some other software layer(s) or component(s) to support the virtualization. Moreover, in some systems, some virtualization code is included in at least one “superior” VM to facilitate the operations of other VMs. Furthermore, specific software support for VMs may be included in the host OS itself. Unless otherwise indicated, the invention described below may be used in virtualized computer systems having any type or configuration of virtualization software.
Moreover, FIG. 1 shows virtual machine monitors 136, 138 that appear as separate entities from other components of the virtualization software. Furthermore, some software components used to implement one embodiment of the invention may be within a “virtualization layer” located logically between all virtual machines and the underlying hardware platform and/or system-level host software. This virtualization layer can be considered part of the overall virtualization software, although it would be possible to implement at least part of this layer in specialized hardware. The illustrated embodiments are given only for the sake of simplicity and clarity and by way of illustration—as mentioned above, the distinctions are not always so clear-cut. Again, unless otherwise indicated or apparent from the description, it is to be assumed that the invention can be implemented anywhere within the overall structure of the virtualization software, and even in systems that provide specific hardware support for virtualization.
The various virtualized hardware components in the VM 102, such as the virtual CPU(s) 120-124, the virtual memory 126, the virtual disk 128, and the virtual device(s) 130, are shown as being part of the VM 102 for the sake of conceptual simplicity. In actuality, these “components” are usually implemented as software emulations 140 included in the VMM 136. One advantage of such an arrangement is that the VMM 136 may (but need not) be set up to expose “generic” devices, which facilitate VM migration and hardware platform-independence.
Different systems may implement virtualization to different degrees—“virtualization” generally relates to a spectrum of definitions rather than to a bright line, and often reflects a design choice with respect to a trade-off between speed and efficiency on the one hand and isolation and universality on the other hand. For example, “full virtualization” is sometimes used to denote a system in which no software components of any form are included in the guest other than those that would be found in a non-virtualized computer; thus, the guest OS could be an off-the-shelf, commercially available OS with no components included specifically to support use in a virtualized environment.
In contrast, another concept, which has yet to achieve a universally accepted definition, is that of “para-virtualization.” As the name implies, a “para-virtualized” system is not “fully” virtualized, but rather the guest is configured in some way to provide certain features that facilitate virtualization. For example, the guest in some para-virtualized systems is designed to avoid hard-to-virtualize operations and configurations, such as by avoiding certain privileged instructions, certain memory address ranges, etc. As another example, many para-virtualized systems include an interface within the guest that enables explicit calls to other components of the virtualization software.
For some, para-virtualization implies that the guest OS 132 (in particular, its kernel) is specifically designed to support such an interface. According to this view, having, for example, an off-the-shelf version of Microsoft Windows XP as the guest OS 132 would not be consistent with the notion of para-virtualization. Others define para-virtualization more broadly to include any guest OS 132 with any code that is specifically intended to provide information directly to any other component of the virtualization software. According to this view, loading a module such as a driver designed to communicate with other virtualization components renders the system para-virtualized, even if the guest OS 132 as such is an off-the-shelf, commercially available OS not specifically designed to support a virtualized computer system. Unless otherwise indicated or apparent, this invention is not restricted to use in systems with any particular “degree” of virtualization and is not to be limited to any particular notion of full or partial (“para-”) virtualization.
In addition to the sometimes fuzzy distinction between full and partial (para-) virtualization, two arrangements of intermediate system-level software layer(s) are in general use—a “hosted” configuration and a non-hosted configuration (which is shown in FIG. 1). In a hosted virtualized computer system, an existing, general-purpose operating system forms a “host” OS that is used to perform certain input/output (I/O) operations, alongside and sometimes at the request of the VMM. The Workstation product of VMware, Inc., of Palo Alto, Calif., is an example of a hosted, virtualized computer system, which is also explained in U.S. Pat. No. 6,496,847 (Bugnion, et al., “System and Method for Virtualizing Computer Systems,” 17 Dec. 2002).
As illustrated in FIG. 1, in many cases, it may be beneficial to deploy VMMs 136, 138 on top of a software layer—a kernel 142—constructed specifically to provide efficient support for the VMs 102, 104. This configuration is frequently referred to as being “non-hosted.” Compared with a system in which VMMs 136, 138 run directly on the hardware platform 106, use of a kernel 142 offers greater modularity and facilitates provision of services (for example, resource management) that extend across multiple virtual machines. Compared with a hosted deployment, a kernel 142 may offer greater performance because it can be co-developed with the VMM 136, 138 and be optimized for the characteristics of a workload consisting primarily of VMs/VMMs. The kernel 142 may also handle any other applications running on it that can be separately scheduled, as well as a console operating system that, in some architectures, is used to boot the system and facilitate certain user interactions with the virtualization software.
Note that the kernel 142 is not the same as the kernel that will be within the guest OS 132—as is well known, every operating system has its own kernel. Note also that the kernel 132 is part of the “host” platform of the VM/VMM as defined above even though the configuration shown in FIG. 1 is commonly termed “non-hosted;” moreover, the kernel 142 may be both part of the host and part of the virtualization software or “hypervisor.” The difference in terminology is one of perspective and definitions that are still evolving in the art of virtualization.